This is a list of Frequently Asked Questions about PHP3 and their answers. If
you have suggestions or additions, send them to php3@lists.php.net.
PHP Version 3.0 is an HTML-embedded scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of unique PHP-specific features thrown in. The goal of the language is to allow web developers to write dynamically generated pages quickly.
On Unix machines, you can use the Sybase-CT driver to access Microsoft SQL Servers because they are (at least mostly) protocol-compatible. Sybase has made a free version of the necessary libraries for Linux systems. For other Unix operating systems, you need to contact Sybase for the correct libraries (which cost money).
Some better alternatives are to use an SQL server that has Windows ODBC drivers and use that to store the data, which you can then access from Microsoft Access (using ODBC) and PHP3 (using the built-in drivers), or to use an intermediary file format that Access and PHP3 both understand, such as flat-files or dBase databases.
php3-subscribe@lists.php.net. You don't need to include anything
special in the subject or body of the message.
To unsubscribe, send mail to php3-unsubscribe@lists.php.net.
joeblow@example.com, you can send your subscription request to
php3-subscribe-joeblow=example.com@lists.php.net, or your
unsubscription request to
php3-unsubscribe-joeblow=example.com@lists.php.net.
To install PHP3, follow the instructions in the INSTALL file located in the distribution. Windows 95 and NT users should also read the README.WIN32 file. There are also some helpful hints for Windows users here: http://leonard.staff.imaginet.fr/Doc/php/configuration_NT.html.
autoconf in the
top-level directory after getting the sources from the CVS server. (Also,
unless you run configure with the --enable-maintainer-mode
option, the configure script will not automatically get rebuilt when the
configure.in file is updated, so you should make sure to do that manually when
you notice configure.in has changed. One symptom of this is finding things
like @VARIABLE@ in your Makefile after configure or config.status is run.
--with-apache=/path/to/apache' and not
'--with-apache=/path/to/apache/src'.
CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configureIf you're using a csh-variant for your login shell (why?), it would be:
env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
cp *.o functions" and then re-running 'make' to see if that
helps. If it does, you should really upgrade to a recent version of GNU make.
If you're linking with Apache 1.2.x, did you remember to add the appropriate information to the EXTRA_LIBS line of the Configuration file and re-rerun Apache's Configure script? See the INSTALL file that comes with the distribution for more information.
Some people have also reported that they had to add '-ldl' immediately following 'libphp3.a' when linking with Apache.
This is actually quite easy. Follow these steps carefully:
while (list($var, $value) = each($HTTP_POST_VARS)) {
echo "$var = $value<br>\n";
}
The ereg_replace magic you're looking for, however, is simply:
$escaped = ereg_replace("'", "\\'", $input);
function myfunc($argument) {
echo $myfunc + 10;
}
$variable = 10;
echo "myfunc($variable) = " . myfunc($variable);
What's going on?
<PRE> 1 <?echo $result[1];?> 2 <?echo $result[2];?>
Why does PHP do this? Because when formatting normal HTML, this usually makes your life easier because you don't want that newline, but you'd have to create extremely long lines or otherwise make the raw page source unreadable to achieve that effect.
$headers = getallheaders();
for(reset($headers); $key = key($headers); next($headers)) {
echo "headers[$key] = ".$headers[$key]."<br>\n";
}
People who aren't thoroughly familiar with the way web servers work and distribute the load may mistake persistent connects for what they're not. In particular, they do not give you an ability to open 'user sessions' on the same SQL link, they do not give you an ability to build up a transaction efficently, and they don't do a whole lot of other things. In fact, to be extremely clear about the subject, persistent connections don't give you any functionality that wasn't possible with their non-persistent brothers.
Why?
This has to do with the way web servers work. There are three ways in which your web server can utilize PHP to generate web pages.
The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections -- they simply don't persist.
The second, and most popular, method is to run PHP as a module in a multiprocess web server, which currently only includes Apache. A multiprocess server typically has one process (the parent) which coordinates a set of processes (its children) who actually do the work of serving up web pages. When each request comes in from a a client, it is handed off to one of the children that is not already serving another client. This means that when the same client makes a second request to the server, it may be serviced by a different child process than the first time. What a persistent connection does for you in this case it make it so each child process only needs to connect to your SQL server the first time that it serves a page that makes us of such a connection. When another page then requires a connection to the SQL server, it can reuse the connection that child established earlier.
The last method is to use PHP as a plug-in for a multithreaded web server. Currently this is only theoretical -- PHP does not yet work as a plug-in for any multithreaded web servers. Work is progressing on support for ISAPI, WSAPI, and NSAPI (on Windows), which will all allow PHP to be used as a plug-in on multithreaded servers like Netscape FastTrack, Microsoft's Internet Information Server (IIS), and O'Reilly's WebSite Pro. When this happens, the behavior will be essentially the same as for the multiprocess model described before.
If persistent connections don't have any added functionality, what are they good for?
The answer here is extremely simple -- efficiency. Persistent connections are good if the overhead to create a link to your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every time it processes a page that requires connecting to the SQL server. This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child.
An important summary. Persistent connections were designed to have one-to-one mapping to regular connections. That means that you should always be able to replace persistent connections with non-persistent connections, and it won't change the way your script behaves. It may (and probably will) change the efficiency of the script, but not its behavior!
If your script uses the regular expression functions (ereg()
and friends), you should make sure that you compiled PHP3 and Apache with the
same regular expression package. (This should happen automatically with PHP3
and Apache 1.3.)
global
$DOCUMENT_ROOT;", for example) or by using the global variable array
(ie, "$GLOBALS["DOCUMENT_ROOT"]".
This has been simplified in PHP3 by the addition of a real string
concatenation operator. If you want to "add" two strings together, just write
it like: "this" . "that" which will result in the string
"thisthat".
The answer to the final part of the question is an emphatic no. Operator overloading can be a source of great confusion, especially when variables aren't very strongly typed to begin with, as they are in PHP3.
chmod($myfile, 0600);not
chmod($myfile, 600);
while (condition);
statement. This will cause PHP3 to spin out of control because it is simply
executing an empty body for your while loop! Change the semi-colon to a colon
and it should work correctly.
function printsum($a, $b) {
echo $a + $b;
}
You can also use old-style function declarations by use the 'old_function' designation, like so:
old_function printsum $a, $b (
echo $a + $b;
);
This FAQ was originally written by Jim Winstead. It is currently maintained by the PHP Development Team.
$Id: FAQ.html,v
1.58 1998/07/08 00:10:44 rasmus Exp $